Amoszine 5/Amoszine 5.adf/arts/STRUCTURING.asc.cm/STRUCTURING.asc.cm

Text File | 1992-02-26 | 5KB | 144 lines

@1                       STRUCTURING YOUR PROGRAMS
                       -------------------------

                         @7 By Richard Martin

@6

      How do you structure your programs? It is a question that can
      cause a lot of people a lot of pain.  If you know anyone who
      has done a A level or has a degree in computing, the first
      thing they will say (usually!) is yuck!  The structure of your
      mega smash hit game is terrible. Doesn't bother them (if they
      are like my brother) if its the most playable game since the
      excellent FRANTIC FREDDIE. (That game is cool!). So what is
      this "structure" they are going on about ?

@3      Basically, the structure is how the program source is set out.
      The main thing to remember about the structure of your program
      is that the most important thing is that YOU understand it and
      YOU can easily de-bug it. However, the rest of the article is
      about how I structure my programs now. It does not mean if you
      read this article this is THE way in which every program must
      be written. If you are happy with the structure of YOUR program
      then keep with it. Just because a program is structure so some
      stuck up professor thinks its good doesn't actually mean the
      program is no good. Look at the source code to some of Brian
      Bells programs (On MAC you dolt!). They have lots of "GOSUBS"
      in them. So what. People who go on about "structured coding "
      would probably have a heart attack. But the actual programs
      are absolutely brilliant and I have learnt a great deal from
      them.

      The first thing I tend to do is comment my work. You may think
      that I would do this anyway, because most of the code I write
      usually ends up on DIDSMAG. (As I edit it you see!). This is
      not the case. I find that if I put comments on every routine,
      and space my work out with comments then it makes the seperate
      commands stand out. The author of the AMOSSIBLE series of PD
      disks has these huge blocks of REM statements then a command
      and a huge block of REM'S again. I find that it takes a while
      to pick out a command from his explanation! You don't quite
      get what I am getting at? Here is an example
@4






      ' This routine will print my magazines name on the screen
      ' 20 times
      '
      For I=1 to 20
      Print"DIDSMAG: 9 BLUNDELL AVE, BIRK...(Oh no you don't you are
      not going to get a plug in that easy! - Ed)
      Next I
      '
      ' Now scroll the screen off
      '
      Def Scroll 1,0,0 to 320,200,-1,0
      '
      ' Start scrolling
      '
      Scroll 1
      '
@3
      Just by looking at it you can see the scroll command. But look
      closely at the FOR/NEXT loop. Its no to easy to see whats going
      on. Just press F3 in the editor and it INDENTS your programs
      This makes it far easier to see whats going on. I indent my
      programs all the time.
@4
      ' The For/Next now becomes:
      '
      For I=1 to 20
            Print "DIDSMAG: 9 BLUNDELL AVE..BIRKDALE..(My god you are
            (persistant!- Ed)
      Next I
      '
@3
      I find this is easier to read. The final thing I am going to
      look at are the actual routines. There are two ways of Storing
      them: Procedures and Labels. I have started using procedures
      for everything I do. I thought I'd tell you why. Up until a
      month or so ago I used LABELS and Gosubs. But the games I am
      programming which use labels are becoming HUGE. (That is Uridi-
      Star and Mouth Man (For WAC) in case you were interested. No?
      Okay then.) With my very latest project: Space Adventures I
      have used procedures for everything I can. I find the ability
      to fold them up is brilliant. I can then have what would be 30
      screens of code in just 2! When I find a bug I just need to
      unfold the relevant procedures with out having to scroll back
      and forth. Procedures can also do easy Parameter passing.
@4



      An example  for you is:

      ' The Labels:
      '
      X=50:Y=150:I=50:N=3:Gosub placeBobz
      '
      PLACEBOBZ:
      '
      For COUNT=1 TO N
            Bob COUNT,X,Y,I
      Next COUNT
      '

      ' Using Procedures:
      '
      '
      PLACEBOBZ[50,50,50,3]
      '
      Procedure[X,Y,I,N]
      For COUNT=1 to N
            Bob COUNT,X,Y,I
      Next COUNT
      End Proc



@3
      As I said earlier though this is not how you MUST code. If you
      have not yet devolped a style that works brillantly yet then I
      suggest you try it out. You never know. You could like it!

      If you need more help, want to tell me about your latest project,
      moan about anything or give me some source code or AMOS programs
      and games, or in fact anything else then do not hesitate to write
      to me at:
@5
      Richard Martin
      9 Blundell Avenue
      Birkdale
      SouthPort
      PR8 4TA
@3
      You can also get issues of DidsMag from here. Send a S.S.A.E and
      two disks for the latest issue. Or you can get it from F1's PD
      Library. Its really very good.

      Richard Martin.